In general, digital data processors generate as a result of executing most instructions one or more "condition codes" which reflect the state of selected "conditions" existing within the hardware comprising the processor as of the time the instruction is completed. For example, as a result of executing an arithmetic or logic instruction on one or more "data operands", the processor may evaluate such condition codes as Zero (Z) if the "result operand" was zero, Negative (N) if the result operand was negative, Overflow (O) if an overflow occured in the Arithmetic and Logic Unit (ALU) as a result of the particular operation, or Carry-out (C) if the ALU provided a carry-out signal as a result of the operation. Often, as a result of executing an instruction requiring the simple movement of a data operand to or from memory or between working registers, the processor will evaluate many of the same condition codes. Typically, the evaluated condition codes are automatically stored in a "condition code register" (CCR) or the like, whether or not they are actually needed. Usually, the contents of the CCR are used by conditional control transfer instructions, such as "branches" or "jumps", executed later in the program. Alternatively, the contents can be moved from the CCR into a working register or to memory using one of the data movement instructions. Thereafter, the individual code bits can be isolated and used as required. However, since the condition codes are often in an very primitive form, synthesis of a more useful logical predicate, such as Greater Than (GT) or Less Than or Equal (LE), usually requires the execution of one or more additional instructions.
Since the processor automatically evaluates the several conditions after the execution of substantially every instruction, the condition codes must be utilized by the very next instruction or not at all. Usually, this is an acceptable limitation, since the condition codes resulting from most operations are used, if at all, to control the following conditional branch instruction. On the other hand, in "pipelined" processors, this limitation becomes less acceptable as the number of stages in the pipeline increases. If the condition codes resulting from a particular operation must be used by more than just the next instruction, that next instruction must transfer the condition codes out of the CCR into a working register or into memory. Otherwise, the original operation must be repeated each time the condition codes are needed. In either event, one or more additional instructions must be executed to make the critical condition codes available when needed.
In some data processors having more than one type of execution unit (EU), the format and meaning of the condition codes for each unit are usually unique. While it is not uncommon to group all condition codes into a single CCR, that practice results in complex scheduling if the EU's have different execution times. It also limits the architectural freedom to change the "mix" of EU's. Additionally, each different type of EU usually requires a corresponding set of conditional branch instructions. This proliferation of instructions makes instruction decoding more difficult, and requires additional hardware to receive the codes, interpret each set of condition codes and control the execution of each branch instruction.
In some other data processors having multiple EU's, the evaluation of condition codes is not implicit, but rather occurs only in response to an explicit request. In some of these processors, a set of "compare and branch" instructions was defined, with the branch being conditioned upon the evaluation of a particular logical predicate. In other processors, a set of "set on condition" instructions are defined, with a result operand being set to the logical truth value of a specified logical predicate. Again, the resulting proliferation of instructions requires additional decode and control logic.